Handling Multiple Inputs
When using Signal start events it is a frequent occurrence to want to have multiple different triggers for a particular process. For example Assets could have several sub-types that all share a set-up process. Here we would want to create a separate trigger for each type of asset like so:
When creating the task to set up the Asset, it would be useful to include the item's name so we can tell which task is which. The problem is we don't know which start event will have fired, so how do we reference the Asset's name?
Coalescing sub-types with data cans
Given that all three asset types share a common name column, we can use a Data Can to 'hold' whichever start event triggered. This will give us a stable single place to reference columns for the 'starting' item.
When referencing elements that haven't triggered, they will behave as if they didn't exist. For example if an IT Asset was created, StartEvent_1twuj1g
would have values inside it, but StartEvent_1
and StartEvent_0tztc2m
would behave as if they were undefined
. In our Lodash implementation undefined
is a falsy (as in false like) value so we can use logical operators to 'pick out' the valid value.
In our example, either StartEvent_1
, StartEvent_1twuj1g
or StartEvent_0tztc2m
will have a value, as at least one start event must have begun the process. We can use the logical OR operator ||
to pick between them. To configure the data can we want to select the ID value of the start event, but trying to access a value on a missing element will return an error. To overcome this we can use optional chaining (the ?.
syntax) to 'try' to access the value and return undefined
if it isn't there. This would end up with a lodash statement like <%= StartEvent_1?.properties?.id || StartEvent_1twuj1g?.properties?.id || StartEvent_0tztc2m.properties.id %>
.
Logical operators process from left to right, so this statement is essentially saying:
- If
StartEvent_1
exists and has an ID value, then use it otherwise - If
StartEvent_1twujig
exists and has an ID value, then use it otherwise - Use
StartEvent_0tztc2m
's ID value
Note how the last choice doesn't use the ?.
optional chain. It could use it, but if none of the three start events have started we have a larger problem (erroring on the last item can help in identifying this problem).
Executing the process, now we have a stable place to pull the name of whatever triggered the run which makes writing our task title nice and easy. For completeness, the task title ends up looking like this:
Ensure asset <%= workflow['Asset'].properties.item.name %> loaded into site